Clarify requires of Prefix/Directive validity requirements#1588
Open
chorman0773 wants to merge 2 commits intorust-lang:masterfrom
Open
Clarify requires of Prefix/Directive validity requirements#1588chorman0773 wants to merge 2 commits intorust-lang:masterfrom
chorman0773 wants to merge 2 commits intorust-lang:masterfrom
Conversation
…ons are required to be obeyed even if the assembly block is never executed.
Amanieu
reviewed
Aug 27, 2024
| If inline assembly includes any "stateful" directive that modifies how subsequent assembly is processed, the block must undo the effects of any such directives before the inline assembly ends. If this constraint is violated, an error may be issued if it can be detected, but otherwise the result of executing the program that contains it is undefined - regardless of whether or not the inline assembly block that contains is eventually evaluated by that execution. | ||
|
|
||
| r[asm.validity.prefix-restriction] | ||
| Inline assembly must not end with an instruction prefix (such as `LOCK`) that would apply to instructions generated by the compiler. If this constraint is violated, an error may be issued if it can be detected, but otherwise the result of executing the program that contains it is undefined - regardless of whether or not the inline assembly block that contains is eventually evaluated by that execution. |
Member
There was a problem hiding this comment.
I would generalize this even more: at the end of the asm block, the CPU must be in a state where it is ready to start a new instruction. Alternatively, the asm block must end at an instruction boundary. This covers cases where you use .byte to only emit a part of an instruction, or leaving the assembler at an unaligned address for architectures that require aligned instructions (e.g. aarch64).
traviscross
added
the
S-waiting-on-author
Collaborator
|
☔ The latest upstream changes (possibly f80986b) made this pull request unmergeable. Please resolve the merge conflicts. |
Contributor
|
@chorman0773 Just checking in, is this something you want to continue working on? |
Contributor
Author
|
Yes, I just haven't had much time to work on it. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This alters the text of the inline-assembly chapter to clarify that ending an inline-assembly block with a prefix or using a "stateful" assembly directive without reverting it results in undefined results whenever the program is executed at all - even if it doesn't eventually evaluate (let alone return from) the assembly block. It also notes that the compiler may (though does not currently) diagnose improper uses of stateful assembly directives that would violate that point.
This also removes the specific application of the prefix to x86 - I do not know whether this applies to any existing supported architectures, but it future proofs adding new such architectures.
Editorially, it also moves the aforementioned rules into the
[asm.validity]section, and renames the identifiers accordingly.CC: @Amanieu